What is the benefit of this? Will it break Retail compatibility? The plan is to abandon STL Port.

What is the benefit of this? Will it break Retail compatibility? The plan is to abandon STL Port.

It is only for vc6 and it doesn't break compatibility. It makes vc6 have more standard library features such as the iostreams and improves thread safety and much more. It will reduce the need for a lot of the macros and compat headers needed to make the code work with both vc6 and vc17.

No mismatch with generals or zero hour
For zero hour tested with golden replay 1 plus others.

All details on the https://discord.com/channels/951133504605917224/1391886820043784282 slack thread

@tomsons26 Do you have any objections about this change?

tomsons26:

I don't know anything about stls, you want @OmniBlade
That said this ignores the fact theres modifications done by EA to stlport
While minor they def would have some impacts
The stlport versions need diffing to understand implications of the changes made in later version
Furthermore no guarantees the sourceforge link works a month from now

The problem with testing a stl change is regular replays tests aren't enough anymore
The stl changes need to be considered individually and their impact on specific code
AFAIK EA didn't update stlport until RA3 if ever
For likely this exact reason
Its not a slap dash change and done as you'd want to believe

It makes vc6 have more standard library features such as the iostreams and improves thread safety and much more. It will reduce the need for a lot of the macros and compat headers needed to make the code work with both vc6 and vc17.

The VC6 compat headers will also be removed when VC6 support is removed.

Was there any observed game/tool issue with STLPort 4.5.3 that this change fixes? Or do the STLPort fixes only have a theoretical benefit?

Given the criticality of STLPort for compatibility, we need to test this change against a few hundred replays.

tomsons26:

I don't know anything about stls, you want @OmniBlade
That said this ignores the fact theres modifications done by EA to stlport
While minor they def would have some impacts
The stlport versions need diffing to understand implications of the changes made in later version
Furthermore no guarantees the sourceforge link works a month from now

As i mentioned already in the main pr comment, the diff was mainly adding pragmas and the newer version already uses pragma once everywhere. The other changes in the diff were adding commented out code. Other than that there were one or two things that the game code itself doesn't use anymore. The rest of the changes are in the changelogs

This change could perhaps also sneakily break save games. So that would need to be tested as well.

I am concerned about this change. It looks very risky.

This change could perhaps also sneakily break save games. So that would need to be tested as well.

I am concerned about this change. It looks very risky.

Then test it well (:

It makes vc6 have more standard library features such as the iostreams and improves thread safety and much more. It will reduce the need for a lot of the macros and compat headers needed to make the code work with both vc6 and vc17.

The VC6 compat headers will also be removed when VC6 support is removed.

Was there any observed game/tool issue with STLPort 4.5.3 that this change fixes? Or do the STLPort fixes only have a theoretical benefit?

Given the criticality of STLPort for compatibility, we need to test this change against a few hundred replays.

whats the relevance if things that will happen when neither version of stlport well be being used

I tested this with some replays as well. No mismatches.

I glanced over it with unassemblize and what it tells is that it introduces massive assembler changes in many functions. From that angle it is risky.

4255 of 19347 functions have less than 100% match

1929 of 19347 functions are not even matching by their mangled name any longer

I glanced over it with unassemblize and what it tells is that it introduces massive assembler changes in many functions. From that angle it is risky.

If it doesn't cause mismatches in 99.9% of games then what difference does it make. Plus it only matters if it changes the deterministic output of functions used for game simulation.

Stlport was the goto stl implementation at the time. You think they would make a minor release that just breaks so much code without even documenting it. A library update, especially a core c++ library, isn't going to make a change all of a sudden like make push_back() add elements in the middle of the vector. You should only check if floating point functions used by our code potentially have changed in such a significant way that they could be optimized differently

Yes the floating point functions are the worry. Since so much code is mutated everywhere, it could be the case that 1 math somewhere produces a different result. Do we want to take this risk for 0 benefits?

Yes the floating point functions are the worry. Since so much code is mutated everywhere, it could be the case that 1 math somewhere produces a different result. Do we want to take this risk for 0 benefits?

It's not 0 benefits. It gives us many more modern features in vc6 and makes the code compile with vc7 and vc8. It allows us to significantly reduce code fragmentatuon.

It will reduce our usage of macros and global compat headers for splitting implementations between vc6 code and vc2022.

-For example it will give us containers like unordered_map and unordered_set meaning we don't have to use the non standard hash_map anymore.

• It will give us the new standard iostreams so we will no longer have to pollute the global namespace with things other using std::cout
• It will improve performance due to performance improvement made to algorithms
• It adds more and better debug functionality for things like detecting memory leaks and memory access violations.
• It fixes bugs in the version of stlport we use right now
• It will make it easier to investigate which parts lead to incompatibility because the code will compile with vc7
• It might make it possible to upgrade to vc7, vc7.1 and even vc8 without breaking compatibility if we can adjust them to use the and optimization settings

Making the code less fragmented, more standard, less buggy, easier to debug, more performant, and especially more readable and therefore maintainable are pretty important benefits

Potentially being able to upgrade to a newer version of visual studio without breaking compatibility is a pretty big pro.

Perhaps we'll be to identify the core compatibility issues and how to mitigate them and we'll be able to upgrade all the way to vs2022 eventually without breaking compatibility

I will leave it to OmniBlade to decide whether we want to go forward with touching STL Port. I do agree with tomsons26 that we should not source this from sourceforge but have our own copy for it.

I will leave it to OmniBlade to decide whether we want to go forward with touching STL Port. I do agree with tomsons26 that we should not source this from sourceforge but have our own copy for it.

Ominblade already said the following in dev general

"The main benefits I see of @aliendroid1 STLPort upgrades is that it allows us to remove some of the ifdef stuff we have now around containers without waiting until we drop retail. If our current replay testing suite passes on the upgrade then I think we are safe that it hasn't changed any logic. If @aliendroid1 wants to do this work I don't see any reason to say not to with the caveat that if it breaks compat it won't be mergable? Seem reasonable"